Skip to content

Conversation

sfackler
Copy link
Member

Nothing inside of the read/write interface itself can panic, so any
poison must have been the result of user code which the lock isn't
protecting.

This seems safe to me, but if we don't want to go this route we should update the docs to indicate that these methods can panic.

r? @alexcrichton

Nothing inside of the read/write interface itself can panic, so any
poison must have been the result of user code which the lock isn't
protecting.
@alexcrichton
Copy link
Member

Hm, I think I tend to agree that ignoring poisoning is probably ok here. I was a little worried about this originally, but I think this works because you're right that the protected state is largely what it would affect and we know it can't panic (and we totally control it) so this should be fine.

If something like rust-lang/rfcs#973 is implemented I'd be a little more worried, but I think it's safe to say that for our own internally managed buffers we'll guarantee that a panic won't happen.

r=me with a test added

@sfackler
Copy link
Member Author

@bors r=alexcrichton a51cd61

Manishearth added a commit to Manishearth/rust that referenced this pull request Mar 19, 2015
 Nothing inside of the read/write interface itself can panic, so any
poison must have been the result of user code which the lock isn't
protecting.

This seems safe to me, but if we don't want to go this route we should update the docs to indicate that these methods can panic.

r? @alexcrichton
@bors bors merged commit a51cd61 into rust-lang:master Mar 19, 2015
@sfackler sfackler deleted the stdio-panic branch November 26, 2016 05:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants